\documentclass[runningheads,a4paper]{llncs}

\usepackage{amssymb}
\setcounter{tocdepth}{3}
\usepackage{graphicx}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{hyperref}
\usepackage{listings}
\usepackage{lscape}
\usepackage{url}
\usepackage{verbatim}
\usepackage{fancyvrb}
\urldef{\mailsa}\path|{johan.bjorn, k.epost, sannatiina}@gmail.com|    
\newcommand{\keywords}[1]{\par\addvspace\baselineskip
\noindent\keywordname\enspace\ignorespaces#1}

\begin{document}

\mainmatter 


\title{Using MDD in Practice:\\Enhancing Productivity and Correctness}

\titlerunning{Using MDD in Practice: Enhancing Productivity and Correctness}

\author{Johan Bjørn
\and Kim Saabye Pedersen \and Sanna Strand}

\authorrunning{Using MDD in Practice: Enhancing Productivity and Correctness}

\institute{IT University of Copenhagen\\
 Rued Langgaards Vej 7\\
 DK-2300 Copenhagen S\\
\mailsa\\
\url{http://www.itu.dk}}


\toctitle{Using MDD in practice}
\tocauthor{Enhancing productivity and correctness}
\maketitle


\begin{abstract}


At KMD as well as many other software companies outsourcing or global delivery
is said to be vital to the future of the company. The mantra is: \emph{everything that is trivial should be outsourced}. We take a different approach as our mantra is: \emph{everything that is trivial should be automated}. The purpose of this paper is to show that automation will not only lead to reduced cost but also to more correct software which again leads to even more reduced cost. We will contrast the current approach to developing software at KMD to the model-driven approach we propose. The results of our investigation are clear. We, three newcomers to domain specific modeling, can model a complex domain and replace use of an advanced enterprise modeling tool in a short period of time. By using the tool we have shown that the code which is generated from our model is correct and automatically generated, hence it is a more productive way of developing software.
\keywords{modeling, automation, savings, correctness}
\end{abstract}


\section{Introduction}

This paper describes a case study where an existing software development process is
converted into a new model-driven development (MDD) process, thereby achieving higher productivity and
correctness in the produced code. Not only was the the new process more
effective than the one that it replaced. The cost of implementing the new model-driven development
process did not exceed the cost of running the original process manually.

A project at KMD uses a tool called  MooD \cite{MooD1} to model state machines.
MooD is an Enterprise Architecture tool for modeling model-driven
solutions. If used properly MooD has a lot of features that would enable it to 
produce models that were usable in a MDD context. Unfortunately, MooD has not been used in a way that make the models produced by it 
usable by MDD tools. For instance the MooD tool is not used to enforce
compliance with the meta models. This allows the user to model state
machines that are not usable for a code generator. 

This has led to somewhat cumbersome process; The MooD models are converted to csv format.
The extracts are validated manually.  It is necessary to consolidate the extracts to make sure they only contain 
the information being displayed in the drawing the user is working on. The extracts often contain up to 600 lines with 6 columns of data. 
They are then parsed by a custom Java program which builds an internal model of the state machine. 
Finally, this internal model is used to generate a Java class that is the executable state machine. 
The different manual evaluations and especially the validation process of the extracts is very time 
consuming and error prone as MooD allows the state machine that is worked on and the underlying data to get out of sync.

In this paper we introduce a prototype - a smarter way to go from a model to
Java code. By implementing this prototype we hope to answer the following two questions: 
\begin{enumerate}
\item Is it possible to implement a MDD-tool that increases the productivity and
improves the quality of the produced code? 
\item Is it feasible to produce such a tool, compared to doing the model to code
conversion manually?
\end{enumerate}
We propose a new tool in which to model state machines that are valid with respect to 
the model consistency rules.  Hence, the tool does not allow invalid machines. This makes any manual 
validation superfluous as the machines are known to be correct. Furthermore, the tool has a "Generate Java code" 
button that generates a Java model of the state machines without any further manual intervention. The generated code is compliant with the existing code base as it implements the same interface as the already manually validated and generated code. 
This leads to better code quality and a shorter work process from a model to code.

%%(KIM: Here will be a section on the evaluation process and the outcome. )
%%(JHB: This part should be droped- start. )
%We argue that our tool gives two main benefits. First, the state machine being
%drawn is valid as it has to conform to a meta model that we define.
%Secondly we save a lot of time on transforming the state machines to Java code as this does not require manual intervention. 
%With regard to the first point we require that the tool we develop can check all constraints that are used 
%in the current KMD tool. With regard to the second point we contrast the time it takes to generate code with 
%the tool we develop to the recorded time we know it takes with the current KMD development approach.
%
%While developing the tool for a better approach to develop the state machines we
%are going to be aware  the time it takes to develop the tool itself.  It would
%not be beneficial to develop a tool which is either too expensive to develop or maintain.
%%(JHB: This part should be droped- start. )
%%( KIM: Here will be  section on how we improve on related work.)


\section{Background}

This section starts by describing the system which consists of state machines. Then the current and the aimed approach for development process is described. Finally, the state machine syntax is presented.

%\emph{"Background provides all the basic information necessary to proceed with reading (for
%a generally educated computer scientist). This could be standard definitions, setting
%notations, etc. This is often necessary to disambiguate from many possible presentations,
%assumptions etc."}

\subsection{The System}
A system being developed at KMD uses executable strategies in order to achieve certain goals. A strategy consists of various collection of tasks that are modeled as state machines, consisting of the various steps in the action (for instance "waiting for event X to occur") and the transitions between the steps (for instance "event X occurred"). The tool we are going to provide models these state machines. 

%An example of a system including state machines could be following: [SANNA: We have to find out an example - it can be whatever]

\subsection{The Development Process}
The current approach for the development of state machines is illustrated in
figure~\ref{process2}.

\begin{figure}
\centering
\includegraphics[scale=0.6]{Pics/process2.png}
\caption {Schematic comparison of old and new approach of developing state machines}
\label{process2}
\end{figure}

A solution architect describes the business requirements by
drawing a collection of tasks in the MooD tool. The outcome of this
description is a drawing, where the model consistency rules are presented as a collection of
state machines. The developer receives the models in XML-form. After validating
the XML-data the developer exports it to csv format. Then the developer makes a manual validation and comparison of the data 
with the drawings. Provided that the data is consistent, the developer parses the data with Java. The result is an internal 
model of the state machine. Provided that parsing succeeded the developer uses the internal model to automatically generate 
a Java class that is an executable state machine.

Our tool implements a simpler process. It is illustrated on the right side of the figure~\ref{process2}. 
First the solution architect describes the business requirements by drawing them with our state machine tool. Then the developer generates automatically all the needed Java code by using the tools that are hooked up to our state machine tool. It is our goal to automate all the manual steps comparing to the current approach.

\subsection{Syntax of the State Machine Language}
 \label{Syntax}

A state machine consists of three different types of components: states,
activities and transitions. There are two types of states. A state can be either
a start  where the state machine is initialized, or it can be an end state,
where there can be an exit point for the state machine. Both transitions and activities
are occurring between the start state and the end state. Transitions are
happening between a state and an activity.

Every state machine must contain at least one activity. An activity is the 
the code that must be executed during transition between two states. Hence a
state machine must contain at least two states and one activity. See figure ~\ref{legal}.

\begin{figure}[t]
\centering
\includegraphics[scale=0.8]{Pics/legal.png}
\caption{A legal state machine.}
\label{legal}
\end{figure}
\begin{figure}[b]
\centering
\includegraphics[scale=0.8]{Pics/illegalOne.png}
\caption{This machine is syntactically incorrect as the same result 'Result'
maps to two distinct states ('STOP STATE ONE' and 'STOP STATE TWO').}
\label{illegalOne}
\end{figure}
The execution of an activity must result in transitioning to exactly one state per result of the activity. An example of a violation to this rule, see figure~\ref{illegalOne}. A state can only trigger the execution of one activity for each event that it can react to (the fan-out is one). Violation to this rule is available in figure~\ref{illegalTwo}. A state machine can contain one or more EXIT states which, when reached, start the execution of another state machine while itself continuing execution. A STOP state can also be an EXIT state.



\begin{figure}[t]
\centering
\includegraphics[scale=0.8]{Pics/illegalTwo.png}
\caption{This machine is syntactically incorrect as the same event is set to initiate the execution of two different activities.}
\label{illegalTwo}
\end{figure}

%Here is an example of an existing state machine:
%[Sanna: her could be an example with a picture? Would "Reservation of a meeting" work?? We should use the same example later on.]

\section{The State Machine }

In this section we introduce the meta model. Thereafter we go into the specifics of how we rectify the shortcomings of the currently used tool. We describe the additional model consistency rules the state machine must adhere to.  

\subsection{The Meta Model}
%KIM: We should describe our model, and what could be done differently, e.g. a more generic model (and describe that an activity is in fact just a special state that sort of generates its own events). A clear advantage of a very specific model is that we can incorporate the  model consistency rules into the syntax.

The meta model contains some of the rules described in the language syntax section \ref{Syntax}. For instance the meta model requires that a state machine has at least two states and one activity.  A state can have a type Start, Normal, Exit or Stop. 
%[Sanna: text is missing here.]

When designing the meta model we were faced with a very basic question: should we have a generic state 
machine meta model that allows the design of many different state machines of
which only a subset  will be valid in our context or should we have a more restricted meta model that
only allows the design of models that are valid in our context? We believe that the power of domain specific 
languages is that they are restricted to  and focus on working well for a particular domain. Likewise we think 
that the best solution in our context is the latter. Hence we have made the meta model shown in figure~\ref{statemachine}.

It is worth noticing that the special GMF \cite{GMF} annotation is a part of the annotations required by EuGENia \cite{EuGENia} and hence not strictly part of the meta model. Likewise the specializations of State, that is the classes Start, Normal, Exit and Stop are present as we would like a different graphical representation in the editor of these different state types and specialization is the only way to achieve this. 
%Should state not be abstract?

%\begin{landscape}
\begin{figure}[t]
\centering
\includegraphics[scale=0.65]{Pics/statemachine2.png}
\caption{The state machine meta model.}
\label{statemachine}
\end{figure}
%\end{landscape}

\subsection{Model Consistency Rules}
\label{constraints}

The model consistency rules are the business rules which have to be adhered
during the design time to ensure the correctness of the code generated in the
end of the process. It means that the architect who is designing the state
machines cannot violate the rules, since they are part of the constraints
regarding the editor.
\begin{enumerate}
\item Every state machine must contain exactly one START state, which is the entry point of the state machine.
\item The execution of all state machines starts with setting the state to the START state.
\item  Every state machine must contain at least one STOP state, which are the exit point(s) of the state machine.
\item Upon transitioning from the START state the state machine must never transition to this state again, hence there are no transitions to the START state.
\item Upon transitioning to the STOP state the execution of the state machine has finished, hence there are no transitions from the STOP state.
\item It is allowed to transition to all states (except the START state) and  activities more than once in the state machine. 
\begin{enumerate}
\item This means that loops are allowed.
\end{enumerate}
\item Every state machine can contain an arbitrary number of states and activities. 
\item A state that is not an EXIT, START or STOP state is set to the NORMAL type.
\end{enumerate}

%See figure~\ref{legal} for an example of a legal state machine.

%Sanna: This is not referred from the text so I comment it out
%\begin{figure}
%\centering
%\includegraphics[scale=0.8]{Pics/illegalThree.png}
%\caption{This state machine violates two rules. (Notice that the same name
%'Result' is allowed for result of two distinct activities)}
%\label{illegalThree}
%\end{figure}

\section{Implementation}

Our choice of tool for developing the editor is EuGENia \cite{EuGENia}, 
which is a tool that automatically generates the models needed to implement 
a GMF editor from a single annotated Ecore \cite{Ecore} meta model. GMF, 
The Eclipse Graphical Modeling Framework \cite{Volter}, provides a generative component and 
runtime infrastructure for developing graphical editors.

Our implementation starts out as a meta model of the state machine. To this
model Emfatic \cite{Emfatic} annotations are added. These annotations tells EuGENia what
graphical representation the elements of the state machine should have, see figure ~\ref{statemach} . 

Based on this annotated meta model EuGENia is able to generate the tool, map and
graph model needed by GMF \cite{proceeding8}. Once the GMF artifacts have been
generated and a plugin containing the validation has been added to the GMF project we are able to run the
editor in Eclipse. 

In the running editor it is possible to compose state machine graphs. The graphs
can be converted in to java code by Xpand \cite{Xpand} via MWE \cite{MWE}. 

The code can be found here: \url{http://code.google.com/p/kf30-e2011}

\begin{figure}[t]
\centering
\includegraphics[scale=0.65]{Pics/overviewMDDIndsatser3.png}
\caption{Overview of the implementation.}
\label{statemach}
\end{figure}

\subsection{Checking Model Consistency}
We have considered several options for implementing the consistency checking. In the following we describe each option along with its strengths and weaknesses and finally why we have chosen to use Java and EVL \cite{EVL}.

\begin{description}
\item[Java:] The advantage of using Java is that we program in Java professionally in daily basis. Hence, there is no learning curve and we can write unit tests for the validation code to check it works as expected. A disadvantage is that Java cannot be plugged into EuGENia.
\item[OCL:]  The advantage of OCL (Object Constraint Language \cite{OCL}) is that the validation automatically plugs into the current Ecore validation framework. Hence, those tools pick up the additional validations with no further intervention. OCL is however very different from our preferred language Java, and the tooling is poor e.g. no good syntax checking. There is no easy way to test our validation rules without involving Eclipse infrastructure which complicates the tests.
%\footnote{Men hvad med Eugenia integration}
\item[Check:] The Check language \cite{Check} can validate a model as part of  MWE modeling workflow execution. However, there are two problems with Check: it is poorly documented and it cannot hook into EuGENias graphical lifecycle and give the user validation feedback in a graphical fashion.
%\footnote{\url{http://help.eclipse.org/indigo/index.jsp?topic=\%2Forg.eclipse.xpand.doc\%2Fhelp\%2Femf\_tutorial\_checking\_contraints\_with\_check.html}}
\item[EVL:] The advantage of using EVL (Epsilon Validation Language \cite{EVL}) is that it directly integrates wih EuGENia. That is, violating rules specified in EVL triggers graphical output in EuGENia as well as in the standard Problem view in Eclipse. EVL is somewhat like OCL and hence our reservations are the same.
\end{description}

We have chosen to use EVL in combination with Java.  Our EVL file is very
minimalistic and it defines the contexts in which we want to define the validation, which rules should be validated for the given contexts and the message that should be displayed to the user in case of violation. The actual validation is dispatched to a Java program. Hence we get the best of all worlds as we get very tight EuGENia integration with visual output as well as we get to leverage our Java competencies. 

\begin{figure}[b]
 \input{Pics/Our-typical-EVL-usage}
  \caption{Our typical EVL usage}
\label{code1}
\end{figure}


The code in figure \ref{code1} shows how we typically use EVL with call out to Java. First we specify the context  in which the rules apply. The rule
\texttt{OneStartState} applies in the context of the whole state machine and the rule \newline
\texttt{noTransitionsFromAStopState} applies to all states. The former rule calls the method \texttt{oneStartState} in the Java program \texttt{main.Validator}. 
The method returns a boolean. If the rule is violated the message will be displayed in the Problem view in Eclipse and an icon (indicating error) will we displayed in the upper right corner of the state machine diagram. In a similar fashion the latter rule calls the \texttt{noTransitionsFromAStopState} method of the Java validator and displays the message pertaining to the rule in case of violation. The error icon will be displayed in the context of the state that violates the given rule. The method \texttt{noTransitionsFromAStopState} from the Java validator is shown in figure \ref{code2}.


\begin{figure}[t]
 \input{Pics/A-method-of-the}
  \caption{A method of the \texttt{main.Validator} class}
\label{code2}
\end{figure}

\subsection{Code Generation}
For the code generation part of our solution we have considered three
technologies; Velocity \cite{Velocity}, JET \cite{JET} and XPand, while being
mindful of desirable characteristics of transformation languages
\cite{proceeding10} \cite{proceeding9}.

\subsubsection{Common traits for the considered technologies}
All three technologies use the same overall strategy to solve
the same problem. They all have a separation between the view, the model and the
control logic. The view contains both the static parts of the code that is generated and an embedded control logic or calls to more advanced control logic. The model represents that part of the problem domain that needs to be turned into
code. The control logic traverses and queries the model in order to generate the variable 
parts of the generated code.

\subsubsection{Differences between the considered technologies}
While having the same overall strategy for solving the same problem, the
technologies differ in the following areas:

\begin{description}
\item[The extend to which they enforce the MVC separation:] In our
evaluation it has been important that the chosen technology enforces the MVC
separation and makes it as easy as possible for the programmer to maintain this separation. 
\item[The languages/technologies used:] The
learning curve involved in adapting a new approach, such as MDD, can be steep.
We value familiar technologies such as the programming language (e.g. Java) or already
known technologies (e.g. JSP).
\item[Ease of integration with our existing technology
setup:] Given the time constraints developing the tool, we had to make sure that the chosen
technology was easy to integrate with our existing choices of technology.
\item[General purpose or dedicated templating solution:] Using
a template solution that is specifically targeted
towards code generation might reduce the learning curve as such a technology
would be easier to learn. On the other hand, a general purpose technology might
already be known and thus have a smaller or no learning curve at all.
\item[The extend to which it is documented:] A technology that is well
documented is favored to a less documented technology. 
\end{description}

\subsubsection{Comparing Velocity, JET and Xpand}
\begin{description}
\item[Velocity: ] 
Is a general purpose template engine with strong separation of functional
responsibility. It is used e.g. as web user interface
generation, e-mail-templating and code generation. This has the clear advantage
that this technology is most likely to be known to programmers. Another advantage is that it is
mostly based on concepts within the 
Java ecosystem. However, the cost of choosing a
general purpose solution such as Velocity is being paid in the long run. The
syntax is not dedicated to the domain of code generation and therefore not
succinct. 
\item[JET: ] The templates of JET looks a lot like the familiar JSP-pages and also have the
same concepts like directives and expressions. Unfortunately the similarity to JSP-pages is also an
disadvantage. JSP-pages are notorious for not enforcing the separation of
concern principle. This leads the expressions and
scriptlet parts of the templates to grow and eventually become unmanageable. 
\item[Xpand: ] 
Is a templating solution targeted towards code generation. It is easy to
integrate into the MWE workflows that executes our code generation. The 
disadvantage of Xpand is that the syntax of the language that controls the
code generation is somewhat strange and takes time getting used to. Luckily, it
is very easy to gain access to Java and its familiar syntax from Xpand. 
\end{description}

We choose Xpand. This decision is mainly based on the ease with which Xpand
integrates with MWE workflows. Also our aim was not to make a strategic
decision about what code generation technology was best suited to be used in KMD
across projects, but simply to choose the technology that helps us to
get a prototype working as fast as possible. Further, we had gained a little experince
with Xpand already in previous projects. 

\subsubsection{Considerations in relation to our code generation}
At first the design of the generated code and the design of the code generator
might not seem that important. However, one only has to work with code generation for a short while before it becomes apparent that these matters
affect the maintainability of the code generator as well as how 'user
friendly' the generated code is.
\begin{description}
\item[Model Aware Vs. Model Ignorant:]  
We decided early on, that the code generated
did not need to differ much from the code generated by the original project. It made our work considerably easier. 
Further, thinking up a new design for the generated code was not one of our
goals. Subsequently, however, it has come to our attention that we could have
chosen a different design for our generated code. One that would have resulted
in markedly less generated code. In \cite{Fowler} a distinction is made
between Model Aware and Model Ignorant-generation. The generation strategy that we have chosen is model ignorant code generation. This means that in the generated code there is no distinction between the code that represents the meta model and the code that represent the specific configuration code. If we had to reimplement the code generation part of the solution, we probably would choose the model aware code
generation model. 
%[Sanna: I think this one is out of scope]
%\item[Manual changes to the generated code:] In our particular case we did not have to think about
% making manual changes to the generated code. Had this 
% been the case, we would have had to include this in our code generation
% strategy. For instance by using the ??? strategy described in \cite{Fowler}.
 \item[Readability of the code: ] To ensure the programmer understands the generated code it is important that the code is well formatted 
 and readable \cite{Volter}. Especially if a programmer has to manually extend the generated code it is important that he can 
 understand what the code is supposed to do without consulting other documentations. Also in a debugging scenario the code has to be readable.
\item[How we generated the code]
According to\cite{Fowler} there are basically two ways of generating code; Transformer Driven Generation 
and Template Driven Generation. Our output has a lot of static parts and fewer dynamic parts. That is why we 
choose the template driven approach for our code generation. Further the template driven approach has the advantage 
that it is possible to have a setup where it is easy to trace which template file
genertes what Java file. In fact, we ended up having one template file pr.
intended Java file. This makes the solution easier to maintain. Using the template approach also means that the content of the template files looks a lot like the Java files they are intended to generate. Again this makes not only maintenance but also creating the templates a lot easier.
\end{description}

\section{Evaluation}

%Sanna: here are the questions from section 1: Is it possible to implement a MDD-tool that increases the productivity and
%improve the quality of the produced code? Is it feasible to produce such
%a tool, compared to doing the model to code conversion manually? 
%Sanna: and the benefits we promise. These goes maybe to the Conclusion?
%We argue that our tool gives two main benefits. First, the state machine being
%drawn is valid as it has to conform to a meta model that we define.
%Secondly we save a lot of time on transforming the state machines to Java code as this does not require manual intervention. 
%With regard to the first point we require that the tool we develop can check all constraints that are used 
%in the current KMD tool. With regard to the second point we contrast the time it takes to generate code with 
%the tool we develop to the recorded time we know it takes with the current KMD development approach.

This section presents the research methods used to measure the results of this study. Furthermore the results are presented. 

\subsection{Methodology}

We used two types of research design to answer the questions we 
wanted answered; An experimental part and a case study part.  The experimental
part of the study shows whether we succeeded in improving the state machine
to code process. The case study part documents how long it took to
develop the tool and what difficulties we encountered. 

The need for measuring the improvement the tools provides should be readily
apparent, our primary goal is to improve the existing process. However, it is
important to remember that any improvement in efficiency of the
existing process should be seen in relation to how long it took to
develop the tool. If it takes longer to create a tool that can automate a
process than to just do the process manually (a limited number of times) then it
is not worth the effort. 

A case study is a strategy where an event is recorded and reviewed in order
to gain an understanding of what can be learned from this event. In our case the
event is our attempt to develop a tool that can improve the efficiency of the
existing process. We have recorded the time it has
taken us to develop the solution. We also recorded other
observations like the decisions we make and where we had particular
difficulties. 

The experimental part answers whether it is possible to improve and 
to what extend the existing development process. Basically what we do is to compare 
the time that has been used creating state machine implementations using the 
current process with the time it takes with the improved process. This is
possible because developers have registered the times they have used
implementing state machines throughout the project. In all 13 state machines
where implemented. Likewise we also recorded the time it takes to run the new
process for those 13 statemachines. 

\subsection{Results}




The total cost of the current solution is 363.25 hours, consisting of:
\begin{itemize}
\item Implementing solution 136.50 hours
\item Implementing state machines using solution  = 226.75 hours
\end{itemize}

\noindent The total cost of our MDD solution is 120.24 hours, consisting of: 
\begin{itemize}
\item Implementing the solution 120 hours
\item Implementing the state machines using solution 0.24 hours
\end{itemize}

\section{Threats to Validity}
The discussion of the validity is written in this section.

\subsection{Threats to Internal Validity}
The experimental part: As the measure obtained post treatment is the result of a completely
automated, repeatable and self contained process. The time it takes to perform the diagram to code transformation is not
influenced by anything else than the input to the process and the design of the
process itself. However, it would have underscored the causal relationship between the treatment and the heightened
efficiency had we had a 'non-treatment' group that where then post-treatment. This would have reduced 
suspicions that threats to the internal validity such as learning or history would have influenced the result.
The validity of it is based on how accurately time has been logged during the
project. It is possible that the developers might have logged too little time or
too much time. If too little time has been logged then any cost reduction
attributed to the new process will be smaller than in reality. If too much time
has been recorded, the cost reductions will look greater than they actually
are. 

\subsection{Threats to External Validity}
The case study part: the biggest threat to external validity is the 
characteristics of the study; we are a small sample constituted of 
volunteers with a particular interest in the subject of MDD. This might 
result in faster implementation of the new MDD solution. Other developers
that are not as motivated might use longer time to implement the MDD solution. 
Thus the result of the case study might not be directly transferable to 
other organizations or developers. Further, as the particular tool we are
building is targeted to a particular problem findings in this part have 
the greatest generalizability for situations where a similar tool is 
being build.  
As was the case in the experimental part, the precision of the time which has been recorded 
influences the validity. Notice, that we have an interest in recording less
time than actually used, to make our findings look as appealing as possible. 

\section{Related Work}

A  lot of case studies about applying MDD in real world projects 
and organizations exist. However, most of these are focused on the 
organizational aspects of introducing a MDD based methodology in a 
development organization. The study \cite{proceeding2} exemplifies this and describes two
companies that try to adopt MDD methodologies. While this study
compares the code centric approach to the MDD centric its focus is broader
than that. It is certainly a worthwhile consideration whether an organization 
or a project type is suitable for MDD methodologies. Our study does not
concern itself with the organizational aspects of introducing MDD. We do
however, recognize it as an obstacle that needs to be overcome if MDD is to be
introduced in an development organization. There is not an abundance of case studies that 
compares the efficiency of MDD  approaches to conventional, code centric, approaches in an real world  setting - and has only this narrow focus. An obvious problem here is that the same software is rarely developed using two different 
approaches in a  commercial setting. The study\cite{proceeding2} describes the development 
of the same  software using a code centric approach and a MDD approach. In 
the case study a considerable amount of time is saved using the MDD approach. 
However, it is not clear from the study if the saved time is due to a framework 
or if it comes from the MDD approach. In our study we use a clean MDD approach. 
The study \cite{proceeding1} is based on a case study that involves developing and using
a MDD tool for developing an autonomic system, compared to developing the 
same system by hand. The domain is much more 
complex and the MDD tool developed contains lots more features. Still it is 
relevant as the goal of the study is the same as this study; to investigate how
MDD centric approaches  compares to the code centric.    

\section {Conclusion and Future Work} 

Doing this project has shown that it was indeed possible to improve the
efficiency of the existing process. The cost of running the state machin
to code process was reduced from 1,5 days to about 1 minute. Equally as
important; the cost of implementing the more efficient solution did not 
exeed the cost of implementing the exisiting solution. 

%\emph{"Summarize the most important outcomes of the paper. Make the sentences sound
%strong (punch!). It should contain the main points that you want the reader (and the
%examiner) to remember.
%It is also customary to include a paragraph about future work: what would, or will,
%you do approach as the next research step after these results."}

\subsubsection{MDD in general}
This project represents a limited part of a much larger project, and one has to
remeber that the generalizability of case studies are limited by their nature.
However, because of the cost reductions shown here, it would be interesting to
see what cost reductions could be obtained in other parts of this or future
projects. 
This project was focused on a very specific domain, state
machines, and required a very customized graphical representation. We could use an MDD approach in other scopes of the project, infrastructure parts e.g.:  data-access layer, webservices, web-frontend. Further, those scopes of the project would not require a customized graphical
representation and could therefore be done using a standart language such as UML (using extensions). Thus the focus of
such future work would be to find the most appropriate tool or collection of
tools that would support this. 
Besides not requirering a special graphical notations, these parts are also
part of many applications and would therefore be reusable across projects, making 
the ROI that much greather.

\subsubsection{The tool developed in this project}
We have several ideas to improve the editor we have made:
We would like to use sub-diagrams in the editor. With this feature very big diagrams could be made more easy to work and understand with by only showing parts of the graph at a given time.  This feature is available in MooD but currently not supported by EuGENia.
%\footnote{Vi har referencer på dette faktum i et af vores issues.}.
In section \ref{constraints} we describe the constraints we currently check at the KMD project. However, other constraints would also be very valuable. The first thing is liveness; Do we risk that the state machine contains paths that are impossible to get out of? This would not be beneficial from a business perspective. The second thing is reachability; Do we have some parts of the graph that are impossible to reach, for instance a STOP state? \cite{proceeding15}

If the state machines get really big, at the moment the largest has about 30 states and 50 activities, or the hardware on which we execute the state machines gets limited we could consider exploiting techniques from \cite{wasowski03} and \cite{wasowski04}. The articles present a way to generate very small code from big state machines. However, at the moment the hardware we execute the state diagrams on is sized big enough hence the code size is not an issue. As future projects at KMD might have different target runtime environments than the current project the techniques might be of use.

\begin{thebibliography}{4}

\bibitem{MooD1} MooD Technology Capabilities \url{http://www.moodinternational.com/MooD_PDFs/MooD_Overview.pdf}

\bibitem{GMF} GMF Graphical Modeling Framework tutorial \url{http://wiki.eclipse.org/GMF} 

\bibitem{EuGENia} EuGENia GMF Tutorial \url{http://www.eclipse.org/gmt/epsilon/doc/articles/eugenia-gmf-tutorial/}

\bibitem{Ecore} Ecore Tools \url{http://wiki.eclipse.org/Ecore_Tools}

\bibitem{Volter} T. Stahl, M. Völter: Model-Driven Software Development: Technology, Engineering, Management. Wiley (2006) 

\bibitem{Emfatic} Emfatic Tutorial \url{http://wiki.eclipse.org/Emfatic}

\bibitem{Xpand} Xpand \url{http://www.eclipse.org/modeling/m2t/?project=xpand}

\bibitem{MWE} Modeling Workflow Engine wiki \url{http://wiki.eclipse.org/Modeling_Workflow_Engine_%28MWE%29}

\bibitem{EVL} Live validation and quick-fixes in GMF-based editors with EVL \url{http://www.eclipse.org/gmt/epsilon/doc/articles/evl-gmf-integration/}

\bibitem{OCL} Model Development Tools: OCL \url{http://www.eclipse.org/modeling/mdt/?project=ocl}

\bibitem{Check} Description of the Check language \url{http://help.eclipse.org/indigo/topic/org.eclipse.xpand.doc/help/Check_language.html}

\bibitem{Velocity} The Apache Velocity Project \url{http://velocity.apache.org/}

\bibitem{JET} The Model to Text (M2T) project: JET \url{http://www.eclipse.org/modeling/m2t/?project=jet#jet}



\bibitem{Fowler} Martin Fowler. Rebecca Parsons. Domain-Specific Languages. Addison-Wesley 2011

%\bibitem{website14} William M.K. Trochim (2012, October 9). "Research Method Knowledge Base". Retrieved from \url{http://www.socialresearchmethods.net/kb/design.php}

\bibitem{proceeding2} Dimitrios S. Kolovos, Louis M. Rose, Nikolaos Drivalos Matragkas,
Richard F. Paige, Fiona A. C. Polack and Kiran J. Fernandes: Constructing
and navigating non-invasive model decorations. In: Proceedings of
the IEEE, Aug 1996, Volume: 84 Issue:8 , pp 1090 - 1123

\bibitem{proceeding1} Kolovos, D.S., Rose, L.M., Nokolaos, D.M., Paige, R.F., Polack
F.A.C., Fernandez K.J.: Constructing and Navigating Non-invasive Model
Decorations. In: Lecture Notes in Computer Science, 2010, Volume 6142/2010

\bibitem {proceeding15} C. Baier, J-P Katoen: Principles of Model Checking. The MIT Press. 2008, pp 31

\bibitem{wasowski03} Wasowski Andrzej: On efficient program synthesis from statecharts. LCTES 2003: 163-170.

\bibitem{wasowski04} Wasowski Andrzej: Flattening statecharts without explosions. LCTES 2004: 257-266.

%\bibitem{proceeding4} Lee, D.; Yannakakis, M.: Principles and methods of testing finite
%state machines-a survey. In: Modeling in Software Engineering, 2009.
%MISE '09. ICSE Workshop on, 17-18 May 2009, pp 13 - 19
%
%\bibitem{proceeding5} Dimitrios S. Kolovos, Louis M. Rose, Saad Bin Abid, Richard F.
%Paige, Fiona A. C. Polack and Goetz Botterweck: Taming EMF and GMF
%Using Model Transformation. In: Lecture Notes in Computer Science,
%2010, Volume 6394/2010, pp 211-225

%\bibitem{proceeding6} Akos Ledeczi, Miklos Maroti, Arpad Bakay, Gabor Karsai, Jason Garrett,
%Charles Thomason, Greg Nordstrom, Jonathan Sprinkle and Peter Volgyesi:
%The Generic Modeling Environment. In: ???

%\bibitem{proceeding7} Davide Di Ruscio, Ralf Lammel, and Alfonso Pierantonio: Automated
%Co-evolution of GMF Editor Models. In: Proceedings of the 32nd ACM/IEEE
%International Conference on Software Engineering, 2010, Volume 1,
%pp 85-94

\bibitem{proceeding8} Kolovos, D.S., Rose, L.M., Nokolaos, D.M., Paige, R.F., Polack
F.A.C.: Raising the level of abstraction in the development of GMF-based
graphical model editors. In: 2009, pp 13-19

\bibitem{proceeding9} D. H. Akehurst, B. Bordbar, M. J. Evans, W. G. J. Howells, K. D.
McDonald-Maier: SiTra: Simple Transformations in Java. In: Lecture
Notes in Computer Science, 2006, Volume 4199/2006, pp 351-364

\bibitem{proceeding10} Sendall, S. Kozaczynski, W.: Model transformation: the heart and
soul of model-driven software development. In: Software, IEEE, Sept.-Oct.
2003, Volume 20 Issue: 5, pp 42 - 45

%\bibitem{proceeding11} Atkinson, C. Kuhne, T.: Model-driven development: a metamodeling
%foundation. In: Software, IEEE, Sept.-Oct. 2003, Volume 20 Issue:
%5, pp 36 - 41
%
%\bibitem{proceeding12} R. Gitzel, A. Korthaus: The Role of Metamodeling in Model-Driven Development. In Proceedings of the 8th World Multi-Conference on Systemics, Cybernetics and Informatics (SCI2004) (2004), pp. 19-21.
%
%\bibitem{proceeding13} F. Jouault, F. Allilaire, J. Bézivin, I. Kurtev, P. Valduriez: 
%ATL: a QVT-like transformation language. In OOPSLA '06 Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications

%\bibitem{Epsilon1} Call Java from Epsilon \url{http://www.eclipse.org/gmt/epsilon/doc/articles/call-java-from-epsilon/}
%\bibitem{Epsilon2} The Epsilon Book \url{http://www.eclipse.org/gmt/epsilon/doc/book/}
%\bibitem{EMF} Eclipse Modeling Framework Project (EMF) \url{http://www.eclipse.org/modeling/emf/?project=emf}

\end{thebibliography}

\end{document}